SOA with .NET and Windows Azure : WCF Extensions - WCF Security

A trust boundary is a physical or virtual boundary within which actual levels of trust can vary. A trust boundary can be an application process, a machine, or even the Internet itself. When SOAP messages flow through a trust boundary, they may need to be transmitted between nodes, through firewalls, across intermediaries, and so on.

Each of these points of contact can introduce message security threats, such as breach of integrity, breach of confidentiality, breach of authentication, and breach of authorization.

A service may be accessed by a service consumer over the Internet or via a local intranet. Cross-service Internet communication typically relies on the exchange of username and password credentials to identify users. On an intranet, Windows security using Active Directory over TCP is common for authentication. Certificates are also frequently used to identify service consumers in both environments.

WCF bindings support confidentiality, integrity, and authentication. It is important to understand that WCF does not automatically provide protection against threats. Attacks, such as SQL injection and XML parser attacks, will generally require attention to service logic and general infrastructure configuration.

Security controls work consistently across bindings. If a binding changes, security settings will simply be carried forward. WCF supports both transport-layer security and message-layer security.

While most of the security detail is incorporated into the platform and preconfigured, two factors need to be considered when designing WCF services and service compositions:

• security mode

• credential type

The security mode is based on credentials. Credentials provide claims made by a service consumer to the service. Claims are packaged in security tokens that are contained in messages that can travel over process and machine boundaries. WCF authenticates and authorizes these claims.

Supported credential types include:

• Username

• Kerberos

• X509

Let’s talk more about security modes and how they process these types of credentials.

Security Modes

Credentials can be transmitted using either the transport security mode (transport-layer security) or the message security mode (message-layer security), as shown in Table 1.

The transport security mode relies on the use of the Secure Sockets Layer (SSL) technology to encrypt the transport. This provides performance benefits and a simplified security architecture. The downside is that it does not support newer and richer types of credentials, such as SAML tokens, and is primarily suitable for point-to-point communication, as opposed to communication that involves intermediaries.

The message security mode enables claims to be secured within the message. It is extensible in support of different credential types (such as SAML) and ensures that protected content cannot be read or tampered with by intermediaries along a given message path. The downside is an increase in runtime processing requirements.

WCF also supports mixed mode security, which allows integrity and confidentiality requirements to be addressed by SSL, while authentication and authorization requirements are satisfied within the message.

Note that when the transport security mode is chosen, authentication requirements can be addressed using the options listed in Table 2.

Security industry standards provide the preferred means of establishing security architectures in support of inherent interoperability among services. These standards include WS-Trust, WS-SecureConversation, WS-SecurityPolicy, WS-Security and the WS-I Basic Security Profile.

A service does not need to be constrained by a single binding or security setting. The same service can be exposed over multiple bindings. For example, one service may be exposed via the Internet using a simple WS-I Basic Security Profile binding over HTTPS, as well as over TCP for local consumers in the same domain using Windows authentication.

Authorization

WCF provides several extensibility hooks that allow you to plug in the authorization policy of your choice and check the validity of the claims.

Supported authorization plug-ins include:

• ASP.NET membership and role providers

• Authorization Manager

• custom-developed code

• .NET role-based security infrastructure

For example, using Thread.CurrentPrincipal is the standard way to access a service consumer’s identity in .NET. If the type of credentials is set to “Windows,” then Thread.CurrentPrincipal will point to WindowsPrincipal and you can determine if the consumer belongs to a valid role by using WindowsPrincipal.IsInRole, as follows:

Example 1.

IPrincipal user = Thread.CurrentPrincipal;
if (user.IsInRole(@"DomainName\contributors "))
{
    ... allow users to contribute ...
}

Federated Identity

In WCF, federated identity represents the ability to enable an organization to accept and process identities issued by other organizations. WCF allows different partner organizations to have the same single sign-on experience, even when they use services that are external to their domain. Federation automates the existing trust relationship between partners, which, in turn, tends to reduce potential mistakes, latency, and maintenance costs.